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Abstract 


Many  people  perceive  DCE  and  CORBA  as  competing  technologies.  Indeed,  both  support  the 
construction  and  integration  of  client-server  applications  in  heterogeneous  distributed  environments. 
Comparisons  typically  focus  on  differences  between  individual  capabilities  or  on  differences  between  the 
maturity  of  specifications  and  products  that  conform  to  them.  There  is  a  fundamental  difference  between 
DCE  and  CORBA,  however,  that  we  feel  far  overshadows  either  of  these  criteria  as  a  basis  for  selecting  a 
distributed  computing  platform.  This  document  summarizes  the  main  features  of  DCE  and  CORBA, 
presents  what  we  feel  is  the  most  important  difference  between  them,  discusses  differences  between 
individual  capabilities  and  the  maturity  of  both  specifications  and  products,  and  concludes  with  our  view 
of  how  an  organization  should  select  the  technology  most  appropriate  to  its  distributed  computing  goals. 

Acknowledgments 


The  author  wishes  to  acknowledge  and  thank  Michael  J.  McGlynn  for  his  technical  input  regarding  DCE, 
his  comments  on  drafts  of  this  document,  and  his  help  designing  the  illustration  of  the  DCE  architecture 
in  Eigure  2. 

This  document  was  written  at  The  MITRE  Corporation  by  the  Distributed  Object  Management 
Integration  System  (DOMIS)  project,  which  is  funded  by  the  Air  Eorce  Electronic  Systems  Center.  The 
project  office  is  at  Rome  Laboratory,  Griffiss  Air  Eorce  Base,  Rome,  New  York.  The  project  officer  is 
Carl  DeEranco,  RL/C3AB.  The  project's  principal  investigator  is  Dr.  Myra  Jean  Prelle,  MITRE. 


Table  of  Contents 


1 .  Introduction 

2.  Overview  of  DCE 

3.  Overview  of  CORBA 


file://///Www-dev/newsite/work/tech_papers/tech_papers_00/brando_domis/index.html  (1  of  19)  [2/5/2003  2:30:02  PM] 


Report  Documentation  Page 

Form  Approved 

0MB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number. 

1.  REPORT  DATE 

MAR  1995 

2.  REPORT  TYPE 

3.  DATES  COVERED 

00-03-1995  to  00-03-1995 

4.  TITLE  AND  SUBTITLE 

Comparing  DCE  and  CORBA 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

MITRE  Corporation, 202  Burlington  Road, Bedford,MA, 01730- 1420 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

The  original  document  contains  color  images. 

14.  ABSTRACT 

15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 
ABSTRACT 

18.  NUMBER 
OF  PAGES 

19 

19a.  NAME  OF 
RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Standard  Form  298  (Rev.  8-98} 

Prescribed  by  ANSI  Std  Z39-18 


Comparing  DCE  and  CORBA 


4.  The  Fundamental  Difference  Between  DCE  and  CORBA 

5.  Differences  Between  Individual  Capabilities 

6.  Maturity  of  the  Specifications  and  Conformant  Products 

7.  Choosing  the  Right  Technology 

List  of  References 

Bibliography 

Glossary 

List  of  Figures 


Figure  1.  Requesting  Seryices  Using  DCE  or  CORBA 

Figure  2.  OSF  DCE  Architecture 
Figure  3.  OMG  CORBA  Architecture 


1.  Introduction 


Many  people  perceiye  the  Open  Software  Foundation  (OSF)  Distributed  Computing  Enyironment  (DCE) 
and  Object  Management  Group  (OMG)  Common  Object  Request  Broker  Architecture  (CORBA)  as 
competing  technologies.  Indeed,  both  support  the  construction  and  integration  of  client-seryer 
applications  in  heterogeneous  distributed  enyironments,  and  both  do  so  in  yery  similar  ways  with  yery 
similar  capabilities. 

Figure  1  depicts  at  a  yery  high  leyel  the  manner  in  which  seryice  requests  are  handled  by  DCE  and 
CORBA.  Both  define  an  Interface  Definition  Language  (IDL).  DCE  IDL  is  based  on  the  C  programming 
language;  CORBA  IDL  is  based  on  C++.  IDL  is  used  to  define  the  interface  that  a  seryer  implements,  that 
is,  the  set  of  seryices  that  clients  may  request  of  it.  Both  DCE  IDL  and  CORBA  IDL  compile  into  client 
and  seryer  stubs.  A  client  application  calls  a  client  stub  to  request  a  seryice.  The  client  stub  interfaces  to 
the  runtime  system,  which  eyentually  inyokes  seryer  code  that  implements  the  requested  seryice  through 
the  appropriate  seryer  stub. 

Figure  1.  Requesting  Seryices  Using  DCE  or  CORBA 
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The  transmission  of  service  requests  and  responses  between  clients  and  servers  is  handled  by  both  DCE 
and  CORBA  so  that  applications  need  not  deal  with  concerns  like:  where  clients  and  servers  are  located 
on  the  network;  differences  between  hardware  platforms,  operating  systems,  and  implementation 
languages  (for  example,  data  formats  or  calling  conventions);  networking  protocols;  and  others. 

There  are  many  other  similarities  between  DCE  and  CORBA,  as  one  would  expect.  However,  our 
purpose  here  is  not  to  present  a  litany  of  the  similarities  between  these  two  technologies.  It  is  our 
intention  to  examine  how  they  differ  from  one  another. 

Comparisons  of  DCE  and  CORBA  are  commonplace;  however,  they  typically  focus  either  on  differences 
between  individual  capabilities  or  on  differences  between  the  relative  maturity  of  specifications  and  of 
products  that  conform  to  them.  There  is  a  fundamental  difference  between  DCE  and  CORBA,  however, 
that  we  feel  far  overshadows  either  of  these  criteria  as  a  basis  for  selecting  a  platform  for  distributed 
computing. 

The  purpose  of  this  document  is  to  discuss  the  differences  between  DCE  and  CORBA  on  all  of  these 
levels.  Before  doing  so,  we  summarize  the  features  that  DCE  and  CORBA  offer.  After  presenting  what 
we  feel  is  the  most  important  difference  between  the  two  technologies,  we  discuss  the  differences 
between  the  individual  capabilities  they  provide  and  the  relative  maturity  of  both  the  specifications  and 
the  products  that  conform  to  them.  Then  we  present  our  view  of  how  an  organization  should  select  the 
technology  most  appropriate  for  its  distributed  computing  goals. 


2.  Overview  of  DCE 


DCE  supports  the  construction  and  integration  of  C-based  client/server  applications  in  heterogeneous 
distributed  environments.  Eigure  2  shows  the  various  elements  that  comprise  the  DCE  architecture. 

Eigure  2.  OSE  DCE  Architecture 
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DCE  Executive 

The  DCE  Executive  consists  of  the  following  components: 

•  Security  Services  that  support  authentication  (using  Kerberos  V5,  clients  and  servers  can  prove 
who  they  are),  authorization  (servers  can  use  access  control  lists  to  determine  whether  a  client  is 
authorized  to  obtain  a  given  service),  integrity  (checksums  guarantee  that  information  is  received 
as  transmitted),  and  privacy  (DES  encryption  protects  sensitive  information  from  disclosure  during 
transmission  between  a  client  and  server). 

•  Directory  Services  that  support  local  DCE  administration  domains  called  cells  and  inter-cell  name 
resolution.  These  services  consist  of  a  Cell  Directory  Service  (CDS),  Global  Directory  Service 
(GDS,  which  uses  X.500),  Domain  Name  Service  (DNS,  not  supplied,  but  used  by  DCE),  and  a 
Global  Directory  Agent  (GDA). 

•  A  Distributed  Time  Service  (DTS)  that  synchronizes  clocks  on  all  hosts  in  a  DCE  cell,  as  well  as 
between  cells.  DTS  uses  the  UTC  standard  and  is  interoperable  with  NTP. 

•  A  Remote  Procedure  Call  (RPC)  mechanism  by  which  clients  invoke  procedures  in  servers.  A 
client  may  use  directory  services  to  bind  to  a  particular  server  of  interest  at  run  time,  and  the  client 
and  server  may  use  security  services  to  guarantee  desired  levels  of  authentication,  authorization, 
integrity,  and  privacy.  The  RPC  mechanism  insulates  clients  from  details  of  where  servers  are 
located  on  the  network,  the  types  of  hardware  and  operating  system  platforms  on  which  they 
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execute,  differences  in  data  representations  between  client  and  server  platforms,  and  the  particular 
network  transports  in  use. 

•  A  Threads  package  based  on  POSIX  1003.4a  (draft  4)  that  supports  the  creation  and  management 
of  multiple  threads  of  control  within  a  client  or  server.  A  multi-threaded  client  may  perform 
additional  work  (perhaps  invoke  additional  RPCs)  while  one  RPC  is  pending.  The  dispatcher  that 
receives  RPCs  at  a  server  and  invokes  the  appropriate  RPC  handlers  is  already  multi-threaded, 
automatically  permitting  DCE  servers  to  handle  multiple  RPCs  concurrently.  The  maximum 
number  of  concurrent  RPCs  at  a  server  is  easily  configured  by  the  developer,  who  is  also 
responsible  for  ensuring  the  thread-safe  behavior  of  all  RPC  handlers. 

DCE  Extended  Services 

DCE  Extended  Services  currently  consist  of  the  Distributed  Eile  Service  (DES)  alone.  The  DES  is  a  DCE 
application  that  implements  a  single  logical  filesystem  that  is  available  (through  Directory  Services) 
throughout  an  entire  cell  and  across  cell  boundaries.  DES  supports  replication  of  files  for  availability  and 
fault-tolerance  and  log-based  recovery  from  hardware  failures. 

The  remaining  components  that  appear  in  Eigure  2  as  DCE  Extended  Services  are  vestiges  of  OSE's 
Distributed  Management  Environment  (DME),  which  failed  to  obtain  vendor  buy-in  and  has  ceased  to 
exist  as  an  entity  in  its  own  right.  These  components  are  shown  in  dashed  boxes  because  it  is  not  clear  at 
this  time  whether  they  will  be  incorporated  into  future  releases  of  DCE.  The  Network  Management 
Option  would  provide  a  means  for  management  applications  to  access  management  information  using 
standard  network  management  protocols  (CMIP  and  SNMP).  The  Event  Service  would  provide  a 
common  way  for  system  and  user  applications  to  generate,  forward,  filter,  and  log  events 

The  Bibliography  lists  sources  of  additional  information  about  DCE. 


3.  Overview  of  CORBA 


CORBA  supports  the  construction  and  integration  of  object-oriented  software  components  in 
heterogeneous  distributed  environments.  Eigure  3  shows  the  various  elements  that  comprise  the  CORBA 
architecture. 


Eigure  3.  OMG  CORBA  Architecture 
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Object  Request  Broker 

An  Object  Request  Broker  (ORB)  provides  a  communication  infrastructure  for  invoking  operations  on 
objects  transparently  with  respect  to  where  they  are  located  on  the  network,  the  types  of  hardware  and 
operating  system  platforms  on  which  they  execute,  differences  in  data  representations  between  platforms, 
the  languages  in  which  objects  are  implemented,  and  network  transports  used  to  communicate  with  them. 
CORBA  specifies  all  of  the  functions  that  must  be  provided  by  an  ORB  and  a  set  of  standard  interfaces  to 
those  functions. 
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CORBA  Services 

CORBA  Services  are  services  that  are  essential  for  implementing  objects.  The  CORBA  Services  that 
have  been  specified  thus  far  by  OMG  include: 

•  A  Concurrency  Control  Service  that  protects  the  integrity  of  an  object's  data  when  multiple 
requests  to  the  object  are  processed  concurrently. 

•  An  Event  Service  that  supports  the  notification  of  interested  parties  when  program-defined  events 
occur. 

•  An  Extemalization  Service  that  supports  the  conversion  of  object  state  to  a  form  that  can  be 
transmitted  between  systems  by  a  means  other  than  a  request  broker. 

•  Life  Cycle  Services  that  support  creation,  copying,  moving,  and  destruction  of  objects. 

•  A  Naming  Service  that  permits  object  references  to  be  retrieved  through  associations  between 
names  and  objects,  and  for  those  associations  to  be  created  and  destroyed. 

•  A  Persistent  Object  Service  that  supports  the  persistence  of  an  object's  state  when  the  object  is  not 
active  in  memory  and  between  application  executions. 

•  A  Query  Service  that  supports  operations  on  sets  and  collections  of  objects  that  have  a  predicate- 
based,  declarative  specification  and  may  result  in  sets  or  collections  of  objects. 

•  A  Relationship  Service  that  provides  for  creating,  deleting,  navigating,  and  managing  relationships 
between  objects  (for  example,  a  containment  relationship  between  a  "folder"  object  and  the 
"document"  objects  that  are  considered  to  be  "in"  that  folder). 

•  A  Transaction  Service  that  provides  support  for  ensuring  that  a  computation  consisting  of  one  or 
more  operations  on  one  or  more  objects  satisfies  the  requirements  of  atomicity  (if  a  transaction  is 
interrupted  by  a  failure,  any  partially  completed  results  are  undone),  isolation  (transactions  are 
allowed  to  execute  concurrently,  but  the  results  are  the  same  as  if  they  executed  serially),  and 
durability  (if  a  transaction  completes  successfully,  the  results  of  its  operations  are  never  lost, 
except  in  the  event  of  catastrophe). 

CORBA  Services  that  are  in  the  process  of  being  specified  and  are  expected  to  be  completed  in  1995 
include: 

•  A  Licensing  Service  that  will  control  and  manage  remuneration  of  suppliers  for  services  rendered. 
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•  A  Property  Service  that  will  support  the  association  of  arbitrary  named  values  (the  dynamic 
equivalent  of  attributes)  with  an  object. 

•  A  Security  Service  that  will  support  authentication,  authorization,  integrity,  and  privacy  to 
degrees,  and  using  mechanisms,  that  are  yet  to  be  determined. 

•  A  Time  Service  that  will  provide  synchronized  clocks  to  all  objects,  regardless  of  their  locations. 
CORBA  Services  that  are  not  yet  in  the  process  of  being  specified  include: 

•  A  Change  Management  Service  that  would  support  the  identification  and  consistent  evolution  of 
configurations  of  objects. 

•  A  Collection  Service  that  would  support  the  creation  and  manipulation  of  collections  of  objects. 

•  A  Data  Interchange  Service  that  would  support  the  exchange  of  data  between  objects. 

•  A  Replication  Service  that  would  provide  for  the  explicit  replication  of  objects  in  a  distributed 
environment  (for  the  purpose  of  availability  or  fault  tolerance)  and  for  the  management  of 
consistency  of  replicated  copies. 

•  A  Trader  Service  that  would  provide  a  matchmaking  service  between  clients  seeking  services  and 
objects  offering  services. 

CORBA  Facilities 

CORBA  Facilities  are  useful  for  constructing  applications  across  a  wide  range  of  application  domains. 
They  are  divided  into  Horizontal  CORBA  Facilities,  which  are  typically  more  user-oriented,  and  Vertical 
CORBA  Facilities,  which  support  specific  application  domains.  The  Horizontal  CORBA  Facilities 
currently  identified  by  OMG  are  grouped  into  four  areas: 

•  User  Interface  Facilities,  which  include  Compound  Presentation,  Desktop  Management,  Rendering 
Management,  Scripting,  and  User  Support  Facilities. 

•  Information  Management  Facilities,  which  include  Compound  Interchange,  Data  Encoding  and 
Representation,  Data  Interchange,  Information  Exchange,  Information  Modeling,  Information 
Storage  and  Retrieval,  and  Time  Operations  Facilities. 

•  System  Management  Facilities,  which  include  Collection  Management,  Consistency, 
Customization,  Data  Collection,  Event  Management,  Instance  Management,  Instrumentation, 
Policy  Management,  Process  Launch,  Quality  of  Service  Management,  Scheduling  Management, 
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and  Security  Facilities. 

•  Task  Management  Facilities,  which  include  Agent,  Automation,  Rule  Management,  and  Workflow 
Facilities. 

No  Horizontal  CORBA  Facilities  have  been  specified  as  yet.  The  first  CORBA  Facilities  RFP  was  issued 
in  October  of  1994  for  Compound  Document  Facilities  (Compound  Presentation  and  Compound 
Interchange).  Further  RFPs  will  be  forthcoming  in  1995. 

The  Vertical  CORBA  Facilities  currently  identified  by  OMG  (as  a  result  of  responses  from  interested 
vertical  market  segments  to  an  OMG  RFI)  are:  Accounting,  Application  Development,  Computer 
Integrated  Manufacturing,  Currency,  Distributed  Simulation,  Imagery,  Information  Superhighways, 
Internationalization,  Mapping,  Oil  and  Gas  Exploration  and  Production,  Security,  and 
Telecommunication.  No  Vertical  CORBA  Facilities  have  been  specified  as  yet. 

The  Bibliography  lists  sources  of  additional  information  about  CORBA. 


4.  The  Fundamental  Difference  Between  DCE  and 
CORBA 


The  fundamental  difference  between  DCE  and  CORBA  is  that  DCE  was  designed  to  support  procedural 
programming,  while  CORBA  was  designed  to  support  object-oriented  programming.  Object-oriented 
programming  environments  are  usually  characterized  by  their  support  for: 

•  Encapsulation  of  data  and  the  functions  that  manipulate  the  data  into  objects.  This  enforces  data 
hiding,  since  the  only  way  to  access  an  object's  data  is  through  the  operations  in  the  object's  public 
interface. 

•  Abstraction  of  common  features  shared  by  objects  into  classes.  A  class  definition  describes  the 
data  associated  with  each  instance  of  the  class,  defines  the  set  of  operations  that  can  be  invoked  on 
an  instance  of  the  class,  and  prescribes  the  functions  that  are  executed  in  response  to  requests  for 
those  operations. 

•  Inheritance  of  interfaces  and  implementations.  This  is  the  mechanism  that  supports  the 
specialization  or  refinement  of  classes  into  subclasses.  It  is  also  one  example  of  reuse  in  object- 
oriented  programming. 

•  Polymorphism,  which  is  the  ability  for  a  request  for  a  specific  operation  to  be  handled  differently 
depending  on  the  type  of  object  on  which  it  is  invoked.  For  example,  subclasses  of  a  common 
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superclass  may  override  functions  defined  by  the  superclass  to  differentiate  how  instances  of  the 
subclasses  and  the  superclass  behave. 

In  addition  to  these  common  characteristics,  object-oriented  programming  environments  usually  support  a 
style  of  programming  in  which: 

•  Not  only  new  objects,  but  new  classes  may  be  created  at  runtime. 

•  Late  binding  of  operation  invocations  to  function  calls  allow  programs  to  be  written  without 
regard  for  the  types  of  objects  they  will  manipulate. 

•  Object  references  are  passed  among  objects  freely,  which  can  lead  to  dynamic  patterns  of  request 
invocations  among  objects  of  arbitrary  types  (by  virtue  of  late  binding). 

•  Once  defined,  objects  and  classes  may  be  reused  or  refined  in  subsequent  applications,  extending 
the  usefulness  of  object  implementations  across  multiple  applications. 

CORBA  supports  all  of  the  common  characteristics  and  programming  styles  described  above,  with  the 
possible  exception  of  creating  new  classes  at  runtime.  We  believe  the  creation  of  new  classes  at  runtime 
may  be  enabled  by  recently  adopted  CORBA  2.0  specifications.  In  particular,  we  refer  to  additional 
Interface  Repository  operations  for  adding  information  to  a  repository  at  runtime  and  a  Dynamic  Skeleton 
Interface,  which  supports  the  implementation  of  servers  capable  of  handling  requests  for  objects  whose 
types  are  unknown  at  compile  time. 

Distributed  procedural  programming  environments  such  as  DCE  support  a  different  set  of  capabilities 
than  those  described  above.  The  basic  approach  to  distributing  a  procedural  program  is  to: 

1.  Partition  the  program's  data  and  the  functions  that  manipulate  the  data  into  servers; 

2.  Distribute  those  servers  across  multiple  hosts;  and 

3.  Change  function  calls  to  RPCs,  as  appropriate. 

This  style  of  programming  does  encapsulate  data  and  functions  in  servers,  because  the  only  way  to  access 
the  data  is  through  the  server's  RPC  interface.  It  does  not  protect  any  of  the  data  within  a  server  from 
access  by  any  of  the  functions  in  the  server,  however.  Nor  does  it  support  abstraction,  inheritance, 
polymorphism,  or  the  dynamic  style  of  programming  described  above. 

DCE  does  have  additional  capabilities  that  begin  to  overlap  with  traditional  capabilities  of  object-oriented 
systems: 

•  A  DCE  client  can  determine  at  runtime  the  specific  servers  to  which  it  will  bind  and  make  RPCs 
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(although  the  interfaces  supported  by  those  servers  must  be  fixed  at  compile  time). 

•  A  DCE  server  may  generate  what  are  called  object  UUIDs  (universal  unique  identifiers)  to  denote 
different  resources  managed  by  the  server.  A  client  that  does  an  RPC  to  the  server  can  use  an 
object  UUID  to  identify  a  specific  resource.  For  example,  a  print  server  might  generate  object 
UUIDs  for  the  different  printers  it  controls,  and  a  client  submitting  a  print  request  would  specify 
the  desired  printer. 

•  A  DCE  server  may  also  generate  what  are  called  object  type  UUIDs,  associate  each  object  UUID 
with  an  object  type  UUID,  and  register  a  separate  set  of  RPC  handlers  for  each  object  type  UUID. 
When  a  client  does  an  RPC  to  the  server  and  specifies  an  object  UUID,  the  specific  function  that  is 
invoked  in  the  server  depends  on  the  object  type  with  which  the  object  UUID  is  associated.  For 
example,  our  print  server  might  associate  one  object  type  UUID  with  RPC  handlers  that  support 
line  printers  and  another  object  type  UUID  with  a  corresponding  set  of  RPC  handlers  that  support 
PostScript  printers. 

One  can  argue  that  these  features  support  some  of  the  characteristics  of  object-oriented  systems  described 
above.  The  object  type  UUID  does  indeed  support  some  form  of  abstraction  and  polymorphism.  The 
important  distinction  to  be  made  here  is  that  procedural  programming  is  not  object-oriented 
programming,  although  it  can  be  used  to  implement  an  object-oriented  programming  environment,  just  as 
C  is  often  used  to  implement  C-h-i-  (that  is  to  say,  C-h-i-  is  often  pre-processed  into  C  before  compilation). 

The  analogy  between  C  and  C-h-i-  is  a  good  one.  Many  CORBA-conformant  ORB  vendors  (DEC,  HP,  and 
IBM,  for  example)  are  implementing  ORBs  on  top  of  DCE.  The  desirability  of  the  object-oriented 
approach  even  within  the  DCE  community  is  evidenced  by  several  efforts  to  provide  C-h-i-  interfaces  to 
DCE  [Dilley,  Leddy,  Mock,  Viveney].  The  OODCE  RFC  [Dilley]  relates  DCE  and  CORBA  as  follows: 

"...our  work  focuses  on  integrating  C-h-i-  within  the  existing  DCE  system  infrastructure, 
simplifying  the  use  of  the  DCE  object  model. 

"OMG  CORBA  will  address  creating  distributed  object  systems  in  C-h-i-;  some 
implementations  will  run  on  top  of  DCE.  CORBA  IDE  provides  for  interface  inheritance, 
which  DCE  IDE  is  lacking,  and  provides  a  more  C-H-i-like  syntax  for  interface 
specification.  The  CORBA  runtime  environment  provides  a  richer  set  of  object  invocation 
and  passing  than  the  DCE  environment. 

"We  suggest  that  our  work  may  assist  in  the  migration  from  DCE  to  CORBA  by  providing 
an  intermediate  C-H-i-based  distributed  object  system  until  CORBA  implementations  are 
widely  available." 
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5.  Differences  Between  Individual  Capabilities 


Although  we  feel  that  the  most  significant  difference  between  DCE  and  CORBA  is  in  the  style  of 
programming  each  is  intended  to  support,  there  are  inevitable  differences  between  the  individual 
capabilities  they  provide.  For  example: 

•  DCE  supports  several  useful  datatypes  that  CORBA  does  not  support: 

o  A  varying  array  in  DCE  is  an  array  of  fixed  size,  of  which  only  part  is  passed  between 
client  and  server;  however,  the  entire  array  is  allocated  at  the  server,  which  may  return 
more  array  elements  than  were  passed  to  it.  CORBA  has  no  equivalent  datatype;  however, 
equivalent  behavior  may  be  obtained  using  a  CORBA  sequence. 

o  DCE  pipes  permit  very  large  parameter  values  to  be  passed  in  a  series  of  smaller  blocks  so 
that  data  transmission  and  processing  may  be  pipelined.  CORBA  supports  no 
corresponding  mechanism  for  dealing  with  very  large  parameter  values;  the  programmer 
can  implement  pipelining  only  by  breaking  up  what  might  be  a  single  operation 
conceptually  into  a  series  of  operations. 

o  DCE  supports  contexts,  which  are  a  mechanism  for  maintaining  server  state  during  a  series 
of  logically  related  requests  from  a  single  client.  (For  example,  the  client  might  be  issuing  a 
series  of  RPCs  to  retrieve  a  set  of  records  from  a  database  one  at  a  time.)  The  server  state  is 
passed  to  the  client  as  an  opaque  context  structure;  the  client  includes  the  context  in 
subsequent  RPCs,  and  the  server  uses  and  modifies  the  state  information  in  the  context,  as 
appropriate.  DCE  provides  support  for  contexts  directly  in  client  and  server  stubs.  CORBA 
has  no  corresponding  mechanism;  the  programmer  is  responsible  for  managing  contextual 
information  explicitly.  (It  should  be  noted  that  DCE  contexts  have  no  relationship  to 
CORBA  contexts,  which  are  used  to  carry  user  preferences  along  with  a  request  to  an 
object.) 

o  DCE  fully  supports  the  use  of  pointers  as,  and  within,  operation  parameters.  An  operation 
that  is  defined  in  DCE  IDE  may  take  a  pointer  as  a  parameter.  Of  course,  such  a  parameter 
is  not  actually  passed  be  ween  a  DCE  client  and  server  as  an  address,  which  is  generally  not 
meaningful  in  a  distributed  environment.  The  DCE  run-time  system  packages  up  the  value 
the  address  points  to  as  part  of  the  process  of  marshalling  the  request  in  preparation  for 
transmission  to  the  server.  Furthermore,  if  a  parameter  is  a  complex  structure  that  contains 
pointers,  the  DCE  run-time  system  will  package  up  all  of  the  values  addressed  by  those 
pointers  during  marshalling,  transmit  them  to  the  server,  and  reconstitute  the  complex 
parameter  with  pointers  in  the  server. 

CORBA  does  not  support  the  use  of  pointers  as,  or  within,  operation  parameters.  The  set  of 
CORBA  IDE  basic  datatypes  and  constructs  for  building  complex  datatypes  do  not  include 
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pointers  (although  they  may  be  implemented  using  pointers).  This  means  that  a 
programmer  may  pass  complex  structures  that  contain  pointers  as  operation  parameters  in 
two  ways.  The  programmer  may  write  additional  code  to  marshall  the  actual  values 
addressed  by  pointers  into  pointer-free  datatypes  in  the  client  and  then  reconstitute  the 
complex  parameter  with  pointers  in  the  server.  Alternatively,  the  programmer  may  redefine 
the  complex  data  structure  as  a  collection  of  one  or  more  objects,  since  CORBA  does 
support  complex  structures  composed  of  objects. 

•  CORBA  supports  an  "any"  data  type  that  DCE  does  not  support.  This  permits  a  value  of  an 
arbitrary  type  to  be  passed  between  a  client  and  server.  The  value  carries  with  it  a  code  that 
indicates  its  type. 

•  DCE  IDE  does  not  support  interface  inheritance  and  defines  a  flat  namespace.  CORBA  IDE 
supports  multiple  inheritance  and  defines  a  hierarchical  namespace. 

•  CORBA  defines  an  Interface  Repository  that  contains  information  equivalent  to  that  in  IDE  files 
and  can  be  queried  at  runtime.  DCE  defines  no  such  repository. 

•  In  addition  to  a  static  (stub)  interface,  CORBA  defines  a  dynamic  invocation  interface  that  can  be 
used  by  a  client  to  invoke  an  arbitrary  operation  on  an  arbitrary  object  type  at  runtime  (supporting 
the  late  binding  of  operation  invocations  to  function  calls).  DCE  defines  no  such  invocation 
mechanism  -  the  appropriate  RPC  stubs  must  be  linked  into  a  DCE  client. 

•  DCE  servers  must  be  brought  up  by  means  external  to  DCE.  CORBA  also  supports  automatic 
server  activation  (in  other  words,  an  ORB  will  bring  up  a  server  if  it  is  not  up  when  a  request  is 
directed  to  it). 

•  The  services  that  DCE  provides  to  an  application  are  rather  limited  compared  to  the  components  of 
the  CORBA  architecture,  which  covers  a  much  broader  spectrum  of  application  support  services 
and  provides  the  developer  with  a  much  richer  set  of  capabilities  on  which  to  build. 


6.  Maturity  of  the  Specifications  and  Conformant 
Products 

DCE  Ontogeny 

OSE  released  DCE  1.0,  including  all  the  DCE  components  described  above,  in  1992.  In  addition  to 
specifications,  OSE  delivered  a  reference  implementation  to  vendors.  By  1993,  the  first  DCE 
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implementations  were  available.  A  partial  list  of  current  DCE  vendors  includes: 

•  AT&T 

•  Bull 

•  DEC 

•  Gradient  Technologies 

•  Hitachi 

•  HP 

•  IBM 

•  Pyramid 

•  SCO 

•  Siemens  Nixdorf 

•  SGI 

•  Stratus 

•  Tandem 

•  Transarc 

OSE  released  DCE  1.1  to  vendors  late  in  1994,  and  vendors  are  expected  to  release  their  implementations 
by  mid-1995.  DCE  1.1  provides  for  enhanced  auditing  and  the  X/Open-approved  GSSAPI  and  Extended 
Registry  Attributes  (ERA).  These  will  permit  enterprises  to  bring  non-DCE  domains  under  the  DCE 
security  umbrella  for  common  enterprise-wide  security  administration. 

OSE  expects  to  release  DCE  1.2  to  vendors  in  two  phases:  DCE  1.2.1  in  November  of  1995  and  DCE 
1.2.2  in  July  of  1996.  The  primary  theme  for  this  release  will  be  to  remove  obstacles  to  broad  end-user 
deployment  of  DCE.  The  focus  areas  for  this  release  are  currently  administration,  ease  of  programming, 
support  for  legacy  systems,  scalability,  security,  and  DES  enhancements. 

While  DCE  continues  to  evolve,  a  number  of  large  end-user  organizations  have  committed  to  basing  their 
next-generation,  enterprise-wide  information  systems  on  DCE. 

CORBA  Ontogeny 

OMG  adopted  the  CORBA  1.0  specification  in  late  1991.  This  included  no  CORBA  Services  or  CORBA 
Eacilities,  nor  did  OMG  release  a  reference  implementation.  By  mid-1993,  the  first  CORBA-conformant 
ORBs  were  available;  by  late  1993,  the  first  CORBA  Services  were  specified  by  OMG.  A  partial  list  of 
vendors  who  are  currently  selling  or  developing  CORBA-conformant  ORBs  includes: 

•  DEC 

•  Expersoft 

•  HP 

•  IBM 

•  IONA  Technologies 
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•  Postmodern  Computing 

•  SunSoft 

At  this  time,  OMG  has  specified  only  nine  of  the  CORBA  Services  and  none  of  the  CORBA  Facilities 
shown  in  Figure  3.  Furthermore,  few  implementations  of  the  CORBA  Services  that  have  been  specified 
are  available  yet.  Nonetheless,  several  large  end-user  organizations  are  prototyping  elements  of  their  next- 
generation,  enterprise-wide  information  systems  using  CORBA. 

Comparison 

Clearly,  DCE  specifications  as  a  whole  are  closer  to  completion  than  CORBA  specifications.  This  is  not 
surprising,  given  the  ambitious  task  OMG  has  undertaken;  Figure  3  is  impressive  in  the  breadth  and  depth 
of  services  it  depicts.  It  is  another  matter  entirely  whether  OMG  will  be  completely  successful  at  defining 
all  of  the  components  in  Figure  3.  As  for  the  maturity  of  DCE  implementations  and  CORBA-conformant 
ORBs,  there  are  mature  examples  of  each. 

Let  us  draw  the  following  distinctions: 

•  The  completeness  of  OSF  and  OMG  specifications  is  one  issue.  DCE  is  certainly  closer  to  being 
fully  specified  than  CORBA  (including  all  of  the  CORBA  Services  and  CORBA  Facilities). 

•  The  maturity  (that  is,  stability)  of  existing  specifications  is  a  second  issue.  Though  all  of  the 
existing  specifications  are  subject  to  revision,  both  OSF  and  OMG  are  attempting  to  do  so  only 
when  necessary  and  to  maintain  backward  compatibility  whenever  possible.  In  this  respect,  both 
the  DCE  specification  and  the  CORBA  specification  (the  ORB  only,  not  including  CORBA 
Services  or  CORBA  Facilities)  are  reasonably  mature  (although  the  CORBA  specification  may 
require  greater  revision  in  view  of  the  large  number  of  services  yet  to  be  specified). 

•  The  completeness  of  conformant  products  as  far  as  implementing  all  of  the  existing  specifications 
is  a  third  issue.  In  this  respect,  there  are  reasonably  complete  implementations  of  both  DCE  and 
CORBA  (the  ORB  only). 

•  The  maturity  (that  is,  stability)  of  conformant  products  is  the  fourth  and  final  issue.  In  this  respect, 
there  are  mature  implementations  of  both  DCE  and  CORBA-conformant  ORBs. 

Regarding  Interoperability 

It  is  common  to  hear  that  DCE  achieved  true  interoperability  in  1992  with  DCE  1.0,  while  CORBA 
interoperability  was  only  recently  specified  and  has  yet  to  be  delivered.  Typically,  each  vendor  ports  DCE 
to  a  specific  platform,  and  interoperability  with  the  reference  implementation  ensures  interoperability 
among  vendors'  implementations. 
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OMG  does  not  deliver  reference  implementations,  only  specifications.  CORBA  1.0  did  not  address 
interoperability  between  ORBs  because  it  was  considered  premature  pending  experience  implementing 
basic  ORB  functions.  As  a  result,  many  vendors  implemented  ORBs  on  a  selection  of  platforms, 
providing  interoperability  across  all  of  the  platforms  supported  by  a  given  vendor.  In  fact,  some  of  the 
ORBs  that  are  currently  available  run  on  over  a  dozen  different  platforms  and  support  interoperable 
clients  and  servers  across  all  of  those  platforms  at  this  time. 

Interoperability  between  ORBs  (that  is,  between  ORB  vendors)  will  be  a  reality  in  1995.  The  Internet 
Inter-ORB  Protocol  (HOP)  specified  by  OMG  in  December  of  1994  [CORBA2]  may  be  supported  via 
bridges  that  can  be  developed  by  end-users  or  third  parties  without  proprietary  information  about  an  ORB 
or  modifications  to  the  ORB.  In  addition,  SunSoft  recently  made  available  on  the  OMG  server  a  public 
domain  implementation  of  the  major  components  needed  to  implement  an  HOP  bridge.  We  therefore 
expect  to  see  widespread  interoperability  among  ORBs  via  HOP  by  late  1995  or  early  1996.  We  expect 
this  even  with  ORBs  that  use  DCE  for  intra-ORB  communication,  although  interoperation  between  DCE- 
based  ORBs  may  be  provided  via  a  DCE- specific  protocol  specified  by  OMG  as  well. 


7.  Choosing  the  Right  Technology 


We  have  stated  that  the  most  important  difference  between  DCE  and  CORBA  is  their  programming 
paradigms:  DCE  was  designed  to  support  distributed  procedural  programming,  while  CORBA  was 
designed  to  support  distributed  object-oriented  programming.  Religious  convictions  must  be  tempered 
with  more  pragmatic  concerns,  however. 

Comparing  the  individual  capabilities  that  each  gives  the  developer,  CORBA  provides  a  much  richer  and 
more  powerful  environment.  Most  of  the  CORBA  services  have  yet  to  be  specified,  however.  Current 
DCE  implementations  provide  services  that  are  not  yet  provided  by  CORBA  implementations  (in  a 
standard  way):  CDS  (Naming),  Security,  DTS  (Time),  and  Threads.  The  CORBA  Naming  Service  has 
been  specified,  and  partial  implementations  are  available  now.  The  CORBA  Security  and  Time  Services 
will  not  be  specified  until  late  1995,  and  we  do  not  expect  to  see  them  available  in  CORBA 
implementations  until  late  1996.  OMG  has  no  plans  at  this  time  to  specify  a  Threads  Service. 

If  these  services  are  essential  to  a  development  effort,  the  alternatives  at  present  are  to  use  CORBA  and 
implement  the  required  services  yourself  or  use  DCE.  If  you  implement  to  OMG-specified  interfaces, 
your  service  implementations  will  eventually  become  superfluous  and  code  that  uses  those  services  will 
port  directly  to  vendor-supplied  implementations,  when  they  are  available. 

If  you  decide  to  use  DCE,  we  suggest  doing  so  with  an  object-oriented  package  like  DEC'S  DCE-h-i- 
[Viveney]  or  HP's  OODCE  [Dilley].  This  will  position  you  to  make  the  transition  to  CORBA  more  easily 
in  the  future.  In  addition,  it  is  important  to  be  aware  that  the  use  of  DCE  datatypes  that  are  not  supported 
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by  CORBA  (pointers,  for  example,  as  discussed  in  Section  5)  can  make  the  transition  to  CORBA 
significantly  more  painful. 

During  the  next  two  years,  the  object  technology  that  OMG  is  specifying  will  migrate  down  into  the 
operating  systems  that  are  delivered  with  workstations  from  all  of  the  major  vendors.  As  a  result  of 
OMG's  recent  adoption  of  CORBA  2.0  specifications  that  include  inter-ORB  interoperability  [CORBA2], 
we  expect  to  see  CORBA  gaining  widespread  acceptance  during  the  next  two  years,  and  we  expect  that 
its  object  orientation  and  rich  set  of  services  will  make  it  the  distributed  computing  platform  of  choice. 
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Glossary 


API 

Application  Programming  Interface 

CDS 

Cell  Directory  Service 

CMIP 

Common  Management  Information  Protocol 

CORBA 

Common  Object  Request  Broker  Architecture 

DCE 

Distributed  Computing  Environment 

DEC 

Digital  Equipment  Corporation 

DES 

Data  Encryption  Standard 

DFS 

Distributed  Eile  Service 
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Comparing  DCE  and  CORBA 


DME 

Distributed  Management  Environment 

DNS 

Domain  Name  Service 

DTS 

Distributed  Time  Service 

ERA 

Extended  Registry  Attributes 

GDA 

Global  Directory  Agent 

GDS 

Global  Directory  Service 

GSSAPI 

Generic  Security  Service  API 

HP 

Hewlett-Packard  Company 

IBM 

International  Business  Machines 

IDE 

Interface  Definition  Eanguage 

HOP 

Internet  Inter-ORB  Protocol 

NTP 

Network  Time  Protocol 

OMG 

Object  Management  Group 

OODCE 

Object-Oriented  Distributed  Computing  Environment 

ORB 

Object  Request  Broker 

OSE 

Open  Software  Eoundation 

POSIX 

Portable  Operating  System  Interface  for  Unix 

REC 

Request  Eor  Comments 

RFI 

Request  Eor  Information 

REP 

Request  Eor  Proposals 

RPC 

Remote  Procedure  Call 

SCO 

Santa  Cruz  Operation 

SGI 

Silicon  Graphics,  Inc. 

SNMP 

Simple  Network  Management  Protocol 

UTC 

Universal  Time  Coordinated 

UUID 

Universal  Unique  Identifier 
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